home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13305 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.5 KB
  1. Path: hypatia.pec.co.nz!JohnM
  2. From: JohnM@hypatia.pec.co.nz (John Marshall)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Coding Standards
  5. Date: 24 Mar 1996 21:59:54 GMT
  6. Organization: PEC (NZ) Ltd.
  7. Message-ID: <4j4gkq$j6c@janus.pec.co.nz>
  8. References: <4hj8ek$elu@sam.inforamp.net> <4hktar$5o2@galaxy.ucr.edu> <4hmqol$97j@abacus.abasoft.co.uk> <4hsg8r$pmm@sam.inforamp.net> <4i9o6j$p4l@daisy.pgh.wec.com> <4idskb$pc1@sam.inforamp.net> <314EBD08.43BC@virtus.com> <4io2i7$n9v@sam.inforamp.net> <4isu2t$opo@jan <4j2jot$svj@sam.inforamp.net>
  9. Reply-To: johnm@pec.co.nz
  10. NNTP-Posting-Host: hypatia.pec.co.nz
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Randy Charles Morin (rmorin@inforamp.net) wrote:
  14. > your post compilation objects are not encapsulated and don't use data hiding. 
  15. > That means, that if your object data member's changes types, then you have to 
  16. > make an effort to conform other objects to your changes.
  17.  
  18. Huh?  My post-compilation objects are monolithic applications, and if my
  19. data types change, they don't know about it until I make the effort to
  20. type "make" to make a new version.
  21.  
  22. > Imagine you are a producing a commercial system for several large 
  23. > corporations.  The large corporation use your hooks (sometimes inline 
  24. > accessors) to add functionality that is dependant on their particular
  25. > business needs.
  26.  
  27. Oh, so I'm writing a *library*.  And it's shipped to users separately from
  28. the applications that use it.  Why didn't you say so?
  29.  
  30. > If you don't have 
  31. > inline accessors, then you don't have a problem.  Is this so hard to 
  32. > understand?
  33.  
  34. Well, yes, as usual it is hard to understand, simply because it's not true.
  35. Inline accessors are only one of the things you have to worry about.
  36.  
  37. For example, if you have classes that the clients can construct themselves,
  38. rather than being limited to getting pointers to them manufactured by your
  39. library, then you can't change their layout or size.  (Many window systems,
  40. such as Amiga and Macintosh, have structs like this.)  So you have to
  41. define your public structs with room for expansion from the start.
  42.  
  43. For example, depending on your DLL technology, you may have to be very
  44. careful about rearranging or adding to the list of externally visible
  45. functions, for fear of changing entry point offsets.
  46.  
  47. On the other hand, if one *is* writing a monolithic application, then inline
  48. accessors are no more harmful than anything else.
  49.  
  50. It seems to me that what developers need is knowledge of all these
  51. implications, rather than just blind adherence to some incomplete rule
  52. like "NEVER use the word inline".
  53.  
  54. John.
  55.